Chip 1996 April

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1996 April / CHIP 1996 aprilis (CD06).zip / CHIP_CD06.ISO / hypertxt.arj / 92 / PDS.CD < prev next >

Wrap

Text File | 1995-09-14 | 28KB | 507 lines

@VJobb késôn mint soha@N @VMicrosoft C/C++ PDS 7.0@N A konkurenciánál jó másfél évvel késôbb, most a Microsoft is kínál fejlesztôi csomagot a C++-ban programozók számára. Kíváncsiak voltunk, hogy megérte-e várakozni. A Microsoft cég C PDS-e mindig is a professzionális szoftverfejlesztôk legkedveltebb segédeszközei közé tartozott. Tavaly azonban a konkurencia alaposan megszorongatta a Microsoft termékét: míg a Microsoft megmaradt a klasszikus C compilernél, addig a többi gyártó, például a Borland és a Zortech már régen az objektumorientált C++-technológiát kínálták. A C/C++ PDS 7.0-val most a Microsoft is belépett az objektumok világába. A compiler front-end kibôvítése C-rôl C++-ra nem az egyetlen újítás a C/C++ PDS 7.0-ban. A debuggertôl a workbenchig szinte mindent továbbfejlesztettek. Ezenkívül az új rendszerbe beépítették a Windows számára készült eddigi Software Development Kit-et (SDK) és a Windows 3.1-hez készült Application Program Interface-t (API). A Microsoft szemmel láthatóan sok munkát fektetett a C/C++ PDS-be. Az új rendszer szuperlatívuszok egész sorát vonultatja fel: -- több mint száz fejlesztô dolgozott az elkészítésén; -- a rendszer tömörített formában tizenegy floppylemezt foglal el. A teljes telepítéshez (beleértve a súgószövegeket és a példaprogramokat) kis híján 30 Mbyte-ra van szükség a merevlemezen. A több mint ötezer oldalas dokumentáció jó tizenkét kilogrammot nyom; -- a compiler csak 386SX vagy efeletti processzorú gépeken futtatható. Aki a C/C++ PDS-sel szeretne dolgozni, annak legalább egy 4 Mbyte memóriájú 386SX géppel és egy 80 Mbyte-os merevlemezzel kell rendelkeznie. Míg a programot lehetséges ugyan (de nem túl bölcs dolog) kisebb merevlemezen (40-80 Mbyte) használni, addig a 386-os vagy 486-os CPU nem takarítható meg. Ennek oka a 32 bites compiler, amely 16 bites gépeken már nem futtatható. A 286-osok, mint fejlesztôi gépek ezáltal végérvényesen elvesztették szerepüket. Az eddigi C PDS-sel ellentétben a C/C++ PDS két telepítô programmal rendelkezik. Az elsô lényegében megfelel annak, amit a fejlesztôk a 6.0-os rendszerbôl ismernek: DOS alatti telepítés -- funkcionális, de nem túl kényelmes. îgy azonban csak egy tiszta DOS-környezetet lehet kiépíteni a compiler számára. A teljes rendszer merevlemezre viteléhez szükség van a második, a Windows által támogatott telepítô programra, amely kényelmesebb, mint a DOS-változat. Aki ismeri az új Quick C for Windows-t, annak bizonyára ismerôsnek tûnik a telepítés. A két telepítô segédeszköz megegyezik a lényeges pontokban. A telepítô program Windows-változatával is létrehozható egy tiszta DOS-változat. Ha a merevlemez kapacitása lehetôvé teszi, akkor azonban ajánlatos a rendszert mind DOS-, mind Windows-változatban kiépíteni. @VTelepítési segítség kezdôk számára@N A rendszer egy párbeszéddobozban konfigurálható. Választani lehet négy különbözô memóriamodell, négy célrendszer (DOS, WINDOWS.EXE, WINDOWS.DLL és QUICKWIN) és három különbözô lebegôpontos könyvtár közül. Ehhez jön még a példaprogramok, a forrásfile-ok és a DOS grafikai könyvtár telepítésének lehetôsége. A programozó tehát valóban nagy kínálatból állíthatja össze saját rendszerét. A kezdôk rendszerint nem tudnak mit kezdeni az ilyen nagy kínálattal. Honnan tudnánk, hogy mi mindenre lesz szükségünk, mielôtt még ismernénk a rendszert. Ezért egy alapkiépítésû rendszert is telepíthetünk. Ha a PDS-sel való munka során mégis szükség lenne egyik vagy másik könyvtárra, akkor az bármikor létrehozható anélkül, hogy ezért a teljes telepítést elölrôl kellene kezdeni. A válogatás közben a telepítô program folyamatosan kiszámítja az összeállított rendszer méretét, s jelzi a célmeghajtón szabadon maradó terület méretét is. A telepítô program kihasználja a Windows multitasking lehetôségeit. Mialatt a másolás és kicsomagolás folyik, a türelmetlen fejlesztô már belekóstolhat a ""readme" file-okba. A floppyk cseréje sem vonja el a figyelmét, mivel azokat csak egyszer kell behelyezni sorban egymás után. A Microsoft végre figyelembe vette a Winword telepítését ért kritikákat. A rendszer telepítéséhez 15--30 Mbyte szabad hely kell a merevlemezen. Ennek oroszlánrészét a könyvtárak használják fel. Teljes telepítéskor pusztán ezek 14 Mbyte-ot foglalnak el. Ehhez jön a header file-ok 1 Mbyte-ja. A compiler és a segédeszközök további 8 Mbyte-ot foglalnak el. A súgórendszerhez jó 4 Mbyte-ra van szükség. Aki példákat és forrásszövegeket is telepít (ami ajánlatos), annak még bô 2 Mbyte-ot kell feláldoznia. A teljes fejlesztôi rendszer központja, akár az elôzô változatban, a ""Programmer's Workbench" (PWB -- programozói munkapad). A PWB ezúttal is tiszta DOS-alkalmazás. Windows alatt csak a DOS-boxban használható. Sok fejlesztô vágyát, hogy a C/C++ compiler valódi Windows-környezetben legyen, a Microsoft még az idén be akarja teljesíteni. A 3.1-es Windows-változattal így lehetôség lesz a Programmer's Workbench Windows-ablakon belüli futtatására anélkül, hogy le kellene mondani az egérrôl. Addig sajnos csak alternatívák vannak: PWB ablakban vagy PWB egérhasználattal. Az eddigi PWB (1.10 verzió) lényeges ismertetôjele volt a szinte már közmondásos komótossága (DOS alatti) programváltás esetén. @VFejlesztési ciklus egy másodperc alatt@N Programozói körökben ezért rosszallóan ""Programmer's Waitbench"-nek is nevezték. A fô probléma a programok tesztelése és a hibakeresés volt. A régi verzióval még egy 486-oson is néhány másodpercig tart egy program elindítása a Workbench-bôl. Még több idô telik el, mire a Workbench a program lefutása után újra munkára készen áll. Ebben a vonatkozásban történt egy s más az új PWB-ben. A teljes ciklus lefutása (indítás-visszatérés) egy gyors gépen már csak egy szûk másodpercet igényel. îgy most tényleg hatékonyan lehet dolgozni, ami jó, mivel a hosszú ciklusidôk miatt a legtöbb fejlesztô egyáltalán nem használta a régi Workbench-et. A PWB lehetôségei így kihasználatlanul maradtak. A Workbench-be be van építve a Microsoft forrásböngészôje (Source Browser). A böngészôk tágabb értelemben CASE (Computer Aided Software Engineering) segédeszközök. A kódgeneráló CASE eszközökkel, mint például a Quick C for Windows-ból való Quick Case W-vel összehasonlítva a böngészôket más célra szánták. Nem a forrásszövegek elkészítésére, hanem azok elemzésére szolgálnak. E segédeszközöket évekig szinte csak Smalltalk környezetekben használták. A Microsoft C programozói már a PDS 6.0-os verziója óta ismerik a Browsert. A C++ világába való belépéssel lényegesen megnôtt a Browser jelentôsége. @VTovábbfejlesztett editor@N Mivel a böngészôket éppen a terjedelmes osztálykönyvtárak esetén érdemes használni, ezért jelentôsen tovább kellett fejleszteni a régi, függvényorientált C Browsert. Az új Browser már nemcsak függvényhívásokat tud elemezni, hanem osztályhierarchiákat is. Már PWB 1.10-nek is egyik nagy erôssége volt a bôvíthetôség. A hagyományos editorokkal ellentétben, amelyek csak makrók segítségével bôvíthetôk, a PWB-t C függvények használatával is hozzá lehet szabni az egyéni igényekhez. E C függvények nem a megszokott startup kódokat tartalmazzák. Indításkor ehelyett a PWB tölti be és inicializálja ôket. A PWB legtöbb belsô funkcióját a C bôvítésekbôl is meg lehet hívni. Ez nagymértékû rugalmasságot enged meg, aminek azonban megvan az ára: aki teljesen ki akarja meríteni a Workbench eme lehetôségét, annak néhány órát rá kell szánnia a kézikönyv tanulmányozására. A PWB C függvényekkel való kibôvítésének lehetôsége elsôsorban azokat a professzionális fejlesztôket célozza meg, akik nap mint nap használják a Workbench-et. A hobby-programozók számára vélhetôen elegendôk a makrók. A már teljesen beépített funkciókon kívül ugyanis még nagyszámú makro áll rendelkezésre, amelyeket a felhasználónak már csak a kívánt billentyûhöz kell kapcsolnia. Az 1.10-es verzióhoz képest további újítás lelhetô fel a környezeti változóknál. Most mindegyiket a Workbench-bôl lehet létrehozni és manipulálni. Ezáltal feloldódik a LIB, az INCLUDE és a HELP korlátozott köre. Sajnos a megváltozott rendszerkörnyezet nem tárolódik automatikusan a projekt-adatoknál. A Workbench megjelenô képe összességében kellemesebb lett. A legfontosabb újítás ezen a területen az egymást átfedô ablakok. A Workbench ebben végre elérte a kornak megfelelô szintet. Az ablakok száma fölöttébb nagyvonalú módon maximálisan 16 lehet. Aki a C compiler 6.0-os verziójából és az SDK-ból álló kombinációval Windows-programok tesztelését és hibakeresését akarta elvégezni, annak lényegében egy dologra volt szüksége: türelemre. A C PDS 6.0 Workbench-e ráadásul nem képes Windows-programokat elindítani. Ezért a Windows-fejlesztôknek kerülô úton, mindig a Windows File Manager-éhez kellett fordulniuk. A Windows-alkalmazások tesztelése elég idegölô volt. A probléma kiküszöbölésére a C/C++ PDS 7.0 tartalmaz egy kis segédeszközt, amelynek neve WX-szerver. A WX-szerver a Windows alatt indítható, és azt figyeli, hogy valamelyik DOS-boxban történik-e kísérlet Windows-program indítására. Ha igen, akkor a WX-szerver közbelép, és elindítja a programot. E megoldással most már a Windows-programok (különösképpen a Codeview for Windows) közvetlenül a PWB-bôl indíthatók. Ezáltal a PWB valamelyest közelebb került egy Windows fejlesztôi környezet funkcionális lehetôségeihez. A C/C++ rendszer két compilerbôl áll, egy a C, egy pedig a C++ programok számára. Mindkét compiler ugyanazt a kódgenerátort használja. Az új compilerek 32 bites flat-model programok, ami magával von néhány következményt: -- a gazdagép teljes memóriája a compilerek rendelkezésére áll. Sok olyan korlátozás, ami megnehezítette a C 6.0A compilerrel végzett munkát, így megszûnt, vagy más területekre tolódott el. Ez elsôsorban a globális optimáló számára jelent elônyt, amelynek eddig mintegy száz sor hosszúságú függvények esetén be kellett vonnia vitorláit. A 32 bites compiler több mint ezer soros függvényeket is könnyen optimál; -- a 32 bites flat-model programok futtatásához szükség van egy DPMI-szerverre (DPMI = DOS Protected Mode Interface). E feladatot vagy a Windows látja el, hiszen van saját, beépített DPMI-szervere, vagy a mellékelten szállított 386Max DPMI-szerver. Azonban a védett módú szolgáltatások is a CPU idejét foglalják le, tehát a DPMI használatakor kissé csökken a teljesítmény. Cserébe a 32 bites utasítások olyan hatalmas elônyöket adnak, hogy a 32 bites flat memóriamodellre való átállás kétségtelenül a helyes irányba mutat. @VMost még jobb az optimálás@N A kódgenerátor mindig is a Microsoft C compilerek erôssége volt. E hagyományhoz méltó az új verzió kódgenerátora is. Az MSC 6.0A compilerhez képest a lényeges továbbfejlesztések az automatikus vagy explicit inlining és a globális optimálás területén történtek. Az explicit inlining technikát már tervbe vették a C++ nyelvi szabványában. Az inline-nak nevezett függvényeket minden meghívásnál közvetlenül a kódba ültetik. îgy az egyébként szükséges belépési és kilépési kódrészek feleslegessé válnak. Kisebb függvények esetén elôfordulhat, hogy ezek a kódok teszik ki a végrehajtáshoz szükséges idô nagyobbik részét. Az inline függvények tehát bizonyos mértékig a makróknak felelnek meg. Mivel a makrók kockázatosak, ezért az explicit inlining technika komoly továbbfejlesztés. Egy lépéssel elôrébb van az automatikus inlining. Ilyenkor a compiler maga dönti el, hogy közvetlenül a kódot használja fel, vagy meghívja a függvényt. Még mélyebbre ható optimálások teszik lehetôvé a compiler számára, hogy minél tökéletesebb kódokat állítson elô. A C 6.0A compilere mindig csak egyes függvényeket tudott optimálni. E határok most kitolódtak. Azonban nem szabad azt elfelejtenünk, hogy már a C 6.0A compiler is igen magas szintû volt. Már a C 6.0A is alaposan kiütötte a nyeregbôl a konkurens Borlandot és Zortechet, és a Watcom compiler sem tudott lényeges elônyöket elérni. Erôsen a lefordított programtól függ, hogy az új optimálások a gyakorlatban valóban lényegesen megnövelik-e a sebességet. Sebességre szabott forráskód esetén már a C 6.0A is nagyon jó kódokat állít elô. Inkább azok a programok jelentenek problémát a 6.0-os compiler számára, amelyek intenzíven használják a kis függvényeket. @VOptimált benchmark@N Ilyenkor az új compilernek sokkal jobbak az eredményei. Lehetôvé teszi a programok megtisztítását anélkül, hogy csökkenne a teljesítmény. Különösen a benchmark programokkal bánik agresszíven a Microsoft compiler. Egyrészt a benchmarkok rendszerint csak kis függvényeket tartalmaznak. Másrészt sok mûvelet felesleges, illetve nincs messzeható következménye a program számára, így a compiler egyáltalán nem állítja elô a mûveletnek megfelelô kódot. Különösen kirívó példa a Dhrystone régi, 1.1 verziója. A C 6.0A egy 25 MHz-es 486DX gépen 20|000 dhrystone-t ér el, az új compiler pedig a mesébe illô 29|500-at. A gyakorlatban igen ritka az ilyen nagyságrendû javulás, s ha mégis megtörténik, akkor a forrásszöveg kifejezetten kis hatékonyságú volt. Valós programoknál a futási idô legfeljebb 10--15 százalékkal javul. A kódminôség jobban látszik az elôállított kód megtekintésekor, mint benchmarkokon keresztül (lásd a listát). A Microsoft állítása szerint már több mint öt éve használja az összes nagy Microsoft program a P-kód technológiát (lásd kiemelt szövegünket). A Microsoft azonban csak most bocsájtja e technikát a többi fejlesztô rendelkezésére. A P-kód használatával komoly tármegtakarítás érhetô el. Aki azt remélte, hogy a 7.0 verzió kódgenerátorával a Microsoft végre a 386-osok speciális parancskészletét (és természetesen a bôvített regisztereket) is ki fogja használni, az csalódik. Most is a 286-os kód a ""csúcsérzés". Aki többet szeretne, annak továbbra is a Watcom vagy a Zortech compilereihez kell fordulnia. Ez a tény annál inkább meglepô, hiszen a Microsoft compiler maga is egy 32 bites flat-model program, amely kihasználja a 386-os és 486-os processzorok speciális lehetôségeit. A professzionális szoftverfejlesztésben nemcsak a végtermék játszik szerepet. Tekintettel kell lenni a programozók idôráfordítására, hiszen messze ez a legnagyobb költségtényezô (legalábbis kisebb szoftverházaknál). A Workbench mellett ezért a compiler is gyorsabb lett. Ehhez elsôsorban két dolog járul hozzá. Egyrészt az elôre lefordított headereket és a típusleíró header file-okat csak egyszer kell lefordítani. Ezután elôfordított formában addig használhatók, amíg nem változtatunk rajtuk. Tapasztalatok szerint viszonylag ritkán változnak meg a header file-ok az implementációs részekhez képest. Másrészt rendelkezésre áll egy új gyorsfordítási lehetôség. Az eddigi @Kquick compile@N (/qc) opció már nincs meg a C/C++ 7.0-ban, felváltotta a @Kfast compile@N (/f) opció. Az új opcióval megszûnnek az eddigi eljárás komoly hátrányai: -- nagy programokat nem lehetett a /qc-vel lefordítani; -- a /qc nem fogadott el minden programszerkezetet. Mind a C mind a C++ fordító kielégíti az ANSI szabványokat (a C++-nál az ANSI 2.1-et). Ezenkívül vannak további Microsoftra jellemzô bôvítések, amelyeket azonban ki lehet kapcsolni. Már a compiler telepítésekor feltûnik, hogy az új C/C++ PDS már nem támogatja az OS/2-t, ezt operációs rendszert nem szánták sem gazdagép- sem célgép-rendszernek. A Microsoft ezt azzal indokolja, hogy minden rendelkezésre álló fejlesztési forrást már befektettek a Windowsba, mivel a piac ezt igényli. Ráadásul az OS/2 éppen egy áttörési fázisban van. Az OS/2 1.x verzióinak napjai meg vannak számlálva, a 2.0 verzió pedig csak nemrég jelent meg. Ami a jövôt illeti, a Microsoft nem zárja ki az OS/2 támogatásának lehetôségét, de konkrétan csupán a compiler egy olyan változatát jelentették be, amely az OS/2 1.x-et gazdagép-rendszerként használja. Erre nagy szükség van, mivel sok fejlesztô dolgozik OS/2 1.x alatt. @VKapcsolat a Windows 3.1-gyel@N Az OS/2 1.x számára programokat író szoftverfejlesztôknek tehát továbbra is a C 6.0A-nál kell maradniuk. A Microsoft az utolsó pillanatban döntött úgy, hogy a Windows 3.1 API-t is beilleszti az új rendszerbe. Vélhetôen azoknak a kritikusoknak akarnak elébe menni, akik már most is a PDS 7.1 verzióján spekulálnak. îgy a C/C++ PDS 7.0 az elsô olyan fejlesztôi rendszer, amely támogatja a Windows 3.1-et. Egy jó fejlesztôi rendszerhez manapság hozzátartoznak a nagyteljesítményû könyvtárak is. Már a C 6.0A is nyújtott ilyesmiket DOS szinten. A Windows világában azonban a Borland utcahosszal vezetett. Az MSC-ben programozóknak még a Windows SDK-val sem volt többje mint a csupasz Windows API. A Borland C++ felhasználói ezzel szemben támogatást kapnak az OWL-tôl, a Borland Object Windows Library-jétôl. Ez a könyvtár leegyszerûsíti a programozást a Windowsban, nagyon jól érvényesül az objektum-koncepció. A Microsoft Foundation Class-okkal és a hozzátartozó Application Framework Class-okkal (AFX) kevesebb mint harminc sor megírásával lehet létrehozni egyszerû Windows programokat. A klasszikus Windows API-val szemben ez óriási könnyebbséget jelent. A Codeview hibakeresônél is történt egy s más. A C++ által megkívánt, kötelezô bôvítéseken kívül további tökéletesítésekre is sor került. A legtöbb fejlesztô számára a legérdekesebb újítás valószínûleg a Remote Debugging (távoli hibakeresés) soros vonalon keresztül. îgy megszûnt az egyik hátrány a Turbo Debuggerhez képest. A hibakeresô kezelése nagy vonalakban ugyanaz maradt, úgyhogy valószínûleg sok programozó továbbra is a Turbo Debuggert használja majd. @VNagy programokat egyszerû kifejleszteni@N A C PDS 6.0 szemmel látható gyenge pontja volt az overlay-kezelés. Például nem volt lehetett adatokat tartani overlay-kben. A lemezre való kimentésért kizárólag a programozó felelt. A modulorientált overlay-koncepció is sok problémát jelentett a C 6.0A-ban. Az eddigi overlay-managerrel nem lehetett a nagy programokat kizárólag logikailag struktúrálni, állandóan figyelni kellett az overlay-struktúrára. A problémák megoldására a Microsoft kitalálta a MOVE-t (Microsoft Overlay Virtual Environment). Ezzel az új overlay-kezelôvel sokkal kicsiszoltabban lehet overlay-ket alkalmazni: a kód és az adatok is lehetnek overlay-kben; a különbözô overlay-kben lévô függvények kölcsönösen meghívhatják egymást; az overlay-ket egy @Klast recently used@N algoritmus koordinálja. Rövidebbek az elérési idôk. @VIntegrálva van a Windows 3.1@N A Windowsban való programozás számára nem elégséges a compiler és a könyvtárak. Windows programok írásához a fejlesztônek további eszközökre van szüksége, például párbeszéd- és ikon-editorokra. A C PDS C 6.0A-ból éppúgy hiányoztak ezek az eszközök mint a Windows header file-ok. Ezek a Windows SDK alkotórészei voltak. Miután a Microsoft C/C++ PDS 7.0-e rendelkezésre bocsájtja a Windows interface-eket, ezek a segédeszközök természetesen már nem hiányozhatnak. A C 7.0 már tartalmazza a Windows 3.1 hibakeresô magját (Debugging Kernel). A C/C++ PDS 7.0 körülbelül 1000 márkába kerül. îgy minimálisra csökkent a távolság a konkurens Borland cégtôl. A Borland C++ 3.0-nak tehát ki kell majd állnia a közvetlen összehasonlítást. Aki már rendelkezik egy Microsoft C PDS-sel, az 300 márkáért átállhat az új verzióra. Az új PDS jelentôs elôrelépés a régi C 6.0A rendszerhez képest. A C++ technológia mellett a fejlesztô kap egy objektumorientált Windows SDK-t is, amit már a Windows 3.1 számára készítettek. A kódgenerátor ismét nagyot lépett elôre (még akkor is, ha még messze nem tökéletes). A C compilerek területén a Microsoft vezetô pozíciója ezáltal továbbra is biztosnak tûnik. Feltétlenül szükséges volt a Workbench felgyorsítása. Az új Workbench-csel végre hatékonyan lehet dolgozni. Azonban a 2.0 verzió sem igazán gyors, e területen még mindig a Borland van elôrébb. A Workbench rugalmassága és mindenekelôtt a kitûnô Source Browser viszont lényeges pluszt jelentenek a PWB számára. A rendszert teljessé teszi a Codeview és az overlay-manager tökéletesítése és a fordítási sebesség növelése. Végezetül kijelenthetjük, hogy érdemes volt várakozni. A Microsoft C/C++ 7.0-val szemben a konkurenciának biztosan nem lesz könnyû dolga. @KChristoph Grunwald@N @VA P-kód tömör@N A P-kód a magas szintû nyelvek és az assembly nyelv keveréke. A P-kód compiler magas szintû nyelvbôl állít elô P-kódot. E keverékkódot azután egy interpreter hajtja végre. A P-kód ezért gyorsabb mint a szokásos magas szintû nyelvi interpreter, de sokkal lassabb mint a valódi gépi kód. A P-kód technikája már viszonylag régóta létezik. Az elmúlt években azonban feledésbe merült. A P-kód rendszerek virágkora a hetvenes évek vége, a nyolcvanas évek eleje volt. Ennek az idôszaknak a legjobban ismert P-kód compilere az UCSD-Pascal volt. A P-kódot akkoriban elsôsorban a hordozhatóság növelése érdekében alkalmazták. Minden új CPU számára pusztán egy P-kód interpretert kellett megírni. Egy új kódgenerátor megírásához képest ez viszonylag egyszerû feladat. Ma már nem fontos ez a szempont. Az Intel 80x86-os sorozattal a PC-világ már binárisan kompatibilis CPU-k széles spektrumával rendelkezik. Most egy másik szempont a döntô, nevezetesen a memóriaigény. A Microsoft P-kód interpreterének mûveletei igen hatásosak, egyetlen P-kód utasítás gyakran több x86-os utasítást is helyettesít. A legtöbb P-kód utasítás kizárólag regiszterben lévô adatokkal dolgozik, így kiesik a címzések nagyrésze. A P-kód technikával összességében akár 50 százalékos tármegtakarítás is elérhetô. Ez az érték persze csak nagy programok esetén érvényes, mivel minden P-kód programnak tartalmaznia kell az interpretert. Maga az interpreter körülbelül 6 Kbyte-os, a P-kód helyigénye pedig mintegy fele a natív kódénak. A kisebb programok tehát nem nyernek a P-kód technikából. Gyors számolással belátható, hogy a P-kód értelmesen csak a legalább 12 Kbyte kódot tartalmazó programoknál használható. Ahhoz, hogy az idôigényes feladatok végrehajthatók legyenek a gyors, x86-os natív kódban, lehetséges a P-kód és a natív kód keverése. @VPéldákkal teszteltük az optimálást@N Egy fejlesztôi segédeszköz minôségét legjobban az elôállított kódból lehet leolvasni. Emiatt több listát is készítettünk. Az 1-es listán egy olyan program látható, amellyel komoly problémái vannak a C 6.0A compilernek. Nem képes optimális kódot elôállítani, mivel az összeadás nem a main()-en belül történik, hanem egy külön függvényben. A 2-es lista a C 6.0A által elôállított kódot mutatja. Egészen más az új compiler. Tökéletesen optimálta a programot. Ehhez számos mûvelet járul hozzá: -- az add() automatikusan inline-olható; -- a compiler már a fordítás ideje alatt kiszámolja az összeadás eredményét. Ezáltal feleslegessé válik a helyi változók elkészítése. A compiler nem is készíti el ôket; -- az add() függvény paramétereirôl is lemondhat a compiler, mivel már egyetlen mûvelet sem történik; -- mivel sem a paraméterekre, sem a lokális változókra nincs szükség, a compiler lemond a veremkeretrôl (stack frame) is. îgy az egész program a printf() meghívására egyszerûsödik. Ezt már valóban nem lehet tovább optimálni. A compiler teljes munkát végzett. Az elsô próba alapján azt a következtetést vonhatnánk le, hogy a C/C++ 7.0 tökéletesen optimál. Sajnos nem ez a helyzet. A 4-es listán elôállított kód azt mutatja, hogy már egy kis átalakítás a programban elegendô ahhoz, hogy az optimáló kiessen a koncepcióból. Az 1-es és 4-es lista csak abban különböznek, hogy a 4-es listában a TEST típus struktúraként van definiálva, míg az 1-es listában @Kint@N volt. Azonban a struktúra is csak egyetlen @Kint@N típust tartalmaz, a program jelentése ugyanaz. A 4-es listában az ideális kód ezért pontosan az lenne, amit a compiler az 1-es listából generált. Ehelyett sokkal rosszabb minôségû gépi kódú programot állít elô. A következô pontok különösen szembetûnnek: -- minden lokális változó és paraméter a el van helyezve, noha a compiler az @Ki3@N-at és a @Ktest@N-et sosem használja; -- a paraméterek átmásolódnak, noha az inline függvény éppolyan jól hozzáférhetne a main() lokális változóihoz; -- az eredmény nincs kiszámolva a fordítási idô alatt. A compiler azonban ennél a programnál is végrehajtott néhány optimálást: -- Az összeadás eredménye az AX regiszterben tárolódik, mivel a compiler felismeri, hogy a printf() meghívása után már nem lesz rá szükség; -- a printf()-bôl való visszatérés után a vermet már nem takarítja ki, mivel a következô utasításban visszaáll az elôzô állapot. A compiler ezt észreveszi; -- az add() függvény inline függvényként mûködik. A példa azt mutatja, hogy a C/C++ 7.0 kódgenerátora ugyan szép teljesítményt nyújt, de még messze nem tökéletes.